Separation kernel with memory allocation, remote procedure call and exception handling mechanisms

ABSTRACT

A computer-implemented system ( 90 ) is provided that supports a high degree of separation between processing elements. The computer-implemented system ( 90 ) comprises a plurality of cells ( 92 ) residing on the computer-implemented system, where each cell ( 92 ) includes a domain of execution ( 94 ) and at least one processing element ( 96 ); a separation specification ( 99 ) that governs communication between the processing elements ( 96 ); and a kernel ( 98 ) of an operating system that facilitates execution of the processing elements ( 96 ) and administers the communication between the processing elements ( 96 ) in accordance with the separation specification ( 99 ), such that one processing element ( 96 ) can influence the operation of another processing element ( 96 ) only as set forth by the separation specification ( 99 ). In particular, the separation specification provides memory allocation, remote procedure calls and exception handling mechanisms.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.10/866,564 filed Jun. 10, 2004 which is a continuation of U.S.application Ser. No. 09/443,597 filed Nov. 19, 1999 now issued as U.S.Pat. No. 6,772,416 on Aug. 3, 2004.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to using the separationprinciple to design a kernel of an operating system, and moreparticularly, the present invention relates to a kernel that applies theseparation principle to memory allocation, remote procedure call andexception handling mechanisms.

2. Discussion

Separation is an extremely important property in the construction andanalysis of secure systems. If two logical entities A and B (forexample, two pieces of software) are separate, then separation meansthat there is no way for A to influence the operation of B, and viceversa. If the operation of A is important to the security of a system,the separation of A and B means that the operation of B can be ignoredwhen evaluating how A supports the security of the system. If A and Bare not separate, so that B could influence the operation of A, thenboth A and B must be considered in evaluating how A supports thesecurity of the system. The necessity of evaluating A and B increasesthe difficulty and cost of the security evaluation, and usually yields alower assurance of security. Thus lack of separation yields thecombination of higher cost and lower assurance.

Complete separation (no influence between A and B) yields a conceptuallyclean system. Incomplete separation can still be very good if there area small (e.g. one, two, or three) number of known influence pathsbetween A and B, and these paths have low bandwidth and/or are difficultto use. Incomplete separation is unacceptable in a high assurance systemwhen it results from the inherent complexity of the system, and theresulting inability to analyze the possible influences between A and B.Therefore, it is desirable to construct a high assurance system applyingstrong separation principles.

Separation is a principal that has been investigated for theconstruction of secure systems for some time. The idea behind separationcan be described with the assistance of FIG. 1. A system is sometimesimplemented as a set of separate physical devices, with the devicesinterconnected by physical wires. In FIG. 1, if it is important to thesecurity of the system that box₁ does not directly intercommunicate withbox₄, then one need only look at the arrangement of the physical boxesand wires to determine the truth of this property.

It is often the case that the same system will be implemented in onephysical box, but with logical entities (e.g. software processes)performing the same functions as the physical boxes of FIG. 1. This newimplementation may result from increasing miniaturization of components,or the increasing memory and processing power available within onprocessor platform. This new implementation of the same system isdepicted in FIG. 2. The tasks are performing the same functions and areinterconnected in the same way as the boxes of FIG. 1. If it wasimportant before that box₁ does not directly intercommunicate with box₄,then it is still important that task₁ does not directly intercommunicatewith task₄. Analyzing the system of FIG. 2 may not be as easy as it wasin FIG. 1. The reason for the increasing difficulty of analysis is shownin FIG. 3.

The problem is that all of the tasks communicate with the operatingsystem, thus the operating system becomes a means whereby informationcan be transmitted between tasks, and tasks can influence each othereven when not permitted by the communication policy of the operatingsystem. FIG. 3 shows task₃ influencing task₁ by means of operatingsystem mechanisms. A standard example of this is memory allocation. Ifall of the tasks allocate memory from a shared pool of resources, thentask₃ could allocate all of the memory. When task₁ runs and attempts toallocate memory, it will receive a failing return from the operatingsystem. This failing return could encode a “1” transmitted from task₃ totask₁. If task₃ then releases some memory, when task₁ runs, it will tryto allocate some memory again, this time receiving a successful returnfrom the operating system. This successful/failure return from theoperating system was never intended to be used as a communicationchannel, nevertheless a good hacker can make use of it in this way. Inother words, the problem is that the other software (e.g., other tasksand the operating system) can now influence the operation of the taskunder analysis, and thus the task under analysis cannot be analyzed inisolation.

Therefore, it is desirable to provide a high-grade separation betweenprocessing elements in a system. This high-grade separation permits thesystem designer to establish high assurance secure systems by allowingeach processing element to be analyzed in isolation. To achievehigh-grade separation, the present invention applies the separationprinciple to the design a kernel of an operating system. Morespecifically, the kernel incorporates memory allocation, remoteprocedure call and exception handling mechanisms in such a way thatsupports the separation concept.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will hereinafter be described in conjunction withthe appended drawing figure(s), wherein like numerals denote likeelements, and:

FIG. 1 is a diagram depicting a box and wire model for a typical systemarchitecture;

FIG. 2 is a diagram depicting a task model that may reside on a physicaldevice in a typical system architecture;

FIG. 3 is a diagram depicting the task model that is supported by anoperating system in a typical multi-tasking architecture;

FIG. 4 is a diagram illustrating the different types of memory segmentssupported by the framework of the present invention;

FIG. 5 is a diagram illustrating the cell abstraction concept of thepresent invention;

FIG. 6 is a diagram illustrating the interaction between cells inaccordance with the present invention;

FIG. 7 is a diagram depicting a single cell and two cell operations inaccordance with the separation principle of the present invention;

FIG. 8 is a diagram depicting a multiple cell abstraction system;

FIGS. 9-11 illustrate the fundamental relationships and equations thatdefine the separation specification of the present invention;

FIGS. 12 and 13 illustrate the first and second separation axioms,respectively, in accordance with the separation specification of thepresent invention;

FIG. 14 depicts a separation kernel that supports a high degree ofseparation between processing elements in a computer-implemented systemin accordance with the present invention;

FIGS. 15-17 illustrate various operations of a strand in a cell inaccordance with the present invention;

FIG. 18 illustrates a method for allocating memory in accordance withthe present invention; and

FIG. 19 illustrates a method for performing remote procedure calls inaccordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention generally relates to designing a kernel of anoperating system in accordance with the separation principle. Aframework for designing the separation kernel is set forth below. It isto be understood that this framework, the subsequent description of theseparation principle and its application to the design of the kernel aremerely exemplary and are intended to provide an understanding of thenature and character of the invention as it is claimed.

In accordance with the present invention, the principle abstraction forthe framework is the cell. A cell is defined as a domain of executionand a collection of strands, where each strand is a stream ofprogrammable machine instructions executable by the kernel of theoperating system. For purposes of the following description, a domain ofexecution is also referred to as the context of the cell and a strand isalso referred to as a task.

The context of a cell is comprised of one or more memory segments. Eachsegment is a range of physical memory addresses, which are defined by astarting address and a length. The framework of the present inventionsupports different types of memory segments as shown in FIG. 4.

Permanent segments are allocated to a cell and therefore are accessibleto any of the strands associated with the cell. Permanent segments maybe used for storing data, code (i.e., a strand's machine instructions)or memory mapped hardware interfaces. Permanent segments cannot be sentin messages, but are retained when the currently executing strand of thecell suspends.

In contrast, a transient segment is accessible to the strand, which isrunning in the cell, and to the cell. In other words, each strand haspredefined memory requirements for its transient segments. When thestrand is launched, the transient segments are allocated for the strand.Thus, the transient segments are accessible to the strand. As will bemore fully explained below, the framework supports different types oftransient segments, such as an input message segment, a scratch segment,an assigned segment, and a register segment.

An overview of the framework, including the cell abstraction concept andits interrelationships, are further discussed in relation to FIG. 5.Each cell can execute only one strand at a time. Strand₃ 22 is currentlyrunning in Cell_(A) 20. It is processing an input message 24, which ismade up of one or more transient segments. Strand₃ 22 may use one ormore scratch segments 26 to process the input message 24. A scratchsegment is a temporary memory space of sufficient size to be used by thestrand when processing the input message. Strand₃ may also access anassigned segment 28. An assigned segment is a specified transientsegment used to gain access to available resources, such as deviceregisters. Lastly, Strand₃ may access one or more permanent segments.For instance, the encapsulated data segment 30 contains static data usedby the strand.

Cell_(B) 32 is currently not executing a strand. However, it may beginexecution of a strand some time after it is granted access to an inputmessage received from Strand₃ 22 of Cell_(A) 20. In FIG. 5, Strand₄ 34is shown being launched in Cell_(B). When a strand in the cell islaunched, the cell receives access to the message segment(s) that makeup the input message. Again, the strand may require scratch segments toprocess the input message. In addition, an interrupt strand may be runimmediately upon receipt of an interrupt. Thus, the execution of astrand may be interleaved with the execution of interrupt strands.

A cell interfaces to its external world (e.g., to other cells or theunderlying hardware) only through the substrate. For purposes of thisdiscussion, the substrate is defined as the operating system, the devicedrivers, and the underlying hardware of the system. Exemplary cellinterfaces are illustrated in FIG. 6. First, the kernel of the operatingsystem launches Strand3 22 of CellA 20. At this time, the strand isgiven access by the kernel to its input message segment(s) and scratchsegment(s). Next, Strand₃ 22 uses a Send interface 36 to send some ofits transient segments to Strand₄ 34 of Cell_(B) 32. As a result,Cell_(A) loses access to the segments transmitted by the strand.

After further execution of the strand, Strand₃ of Cell_(A) addresses anexception condition through the use of a Throw interface 38. Theinterface terminates execution of the strand and initiates execution ofa Handler function. When execution of Strand₃ of Cell_(A) terminates,the kernel removes access to all of the transient segments remaining inCell_(A). If Strand₃ of Cell_(A) had not terminated via the exceptioncondition, it would have reached the end of its strand. In this case,the TerminateStrand interface 39 terminates the execution of the strandand removes access to any transient segments still accessible to thecell. One skilled in the art will readily recognize that the separationkernel of the present invention will be designed and implemented withinthe above-described framework. Data structures that define and describethe strands and cells in the above-described framework are furtherdiscussed in the Appendix.

An introduction to the separation principle is provided in relation toFIGS. 7-11. FIG. 7 shows a cell 40 and two of its operations, Fiberinit42 and FiberNext 44. Again, the cell represents an execution domain.Moreover, the cells are the components of the system to be separated.

In FIG. 8, several cells have been combined into a system 50 that isreferred to as the Multiple Cell Abstraction, where each individual cellis referred to as a Single Cell Abstraction (SCA). Each cell has its ownFiberinit and FiberNext operations, whereas the system as a whole has anInit 52 and Next 54 operation. Since the cells serve as the Fibers ofthe system, the names for the cell level operations are Fiberinit andFiberNext. The names Init and Next are reserved for the system leveloperations.

There are several choices for defining the relationship between thesecell operations. For instance, the Next operation (advancing the systemstate) could correspond to a FiberNext operation (advancing a cellstate) on every cell at once, thereby implying multiprocessing of thecells. On the other hand, the Next operation could correspond to aFiberNext operation on only one cell or on some subset of the cells.There are similar design choices for the Init and Fiberinit operations.The separation specification of the present invention defines the Nextoperation to advance a cell state only one cell at a time and the Initoperation to initialize the cell state of all the cells at once.Therefore, the system state advances one cell at a time, but theinitialization of the system is not complete until all of the cells areready to run.

FIG. 9 depicts this design choice for the separation specification ofthe present invention. In this figure, the Next_(B) operation 62 isbeing performed on the system, where the Next_(B) operation is the Nextoperation performed on Cell_(B). The state of the system before the Nextoperation is shown as MCA State₁ 64. MCA State₁ 64 includes Cell_(A) instate SCA_(A1) 66, Cell_(B) in state SCA_(B1) 68 and Cell_(C) in stateSCA_(C1) 70. The state of the system after the Next operation is shownas MCA State2 72, where Cell_(A) is in state SCA_(A2) 74, Cell_(B) is instate SCA_(B2) 76 and Cell_(C) is in state SCA_(C2) 78. The Next_(B)operation at the system level corresponds to selecting a cell andadvancing the state of that one cell.

FIG. 9 further illustrates that performing Next_(B) on MCA₁ achieves thesame result as taking Fiber_(B) 80 of MCA₁ to yield SCA_(B1) 82, andthen performing FiberNext 84 on SCA_(B1). In this case, Cell_(B) isselected by the Fiber_(B) operation. Performing the FiberNext operationupon CellB advances the state of Cell_(B). In equation form, this is:

Fiber_(B)(Next_(B)(m))=FiberNext(Fiber_(B)(m))

FIG. 10 is a commuting diagram, which is a diagrammatic form of theabove equation. The internal cells of MCA have been hidden from theexternal world and can be observed only through the Fiber operation.This equation can be further shortened to:

Fiber_(B)·Next_(B)=FiberNext·Fiber_(B)

In this short form, the variable m has been dropped. In addition, theequation is between two functions, rather than the value of thefunctions at an arbitrary input. The · symbol denotes functioncomposition.

The final form of this relationship is shown in FIG. 11. In this figure,the functions Next_(B) and Fiber_(B) have been uncurried into Next andFiber. This means that the function Next_(B) is related to Next by theequation Next_(B)(m)=Next(m, B) for Cell_(B). In general, NextX isrelated to Next by the equation NextX(m)=Next(m, x) for any cell X.Since Next_(B) was changed to Next, and Fiber_(B) was changed to Fiber,the CellID parameter is no longer contained in the subscript of theoperator, so this must be made explicit in the domain of the Next andFiber functions. This is why MCA is combined with CellID in the productMCA X CellID. The equations corresponding to FIG. 11 are given asfollows:

Fiber(Next(m, c))=FiberNext(Fiber(m, c))

Fiber·Next=FiberNext·Fiber

In simple terms, what these fundamental equations are saying is thatwhen the system state is advanced by one step, the change in the systemstate corresponds to a change in the state of one of its cells, asidentified by the Fiber function. If you look at the system state beforeadvancing it one step and again after advancing it one step, then therewill be a unique cell c, which accounts for this advance in the state ofthe system. This cell c accounts for the advance in the state of thesystem by advancing its own single cell state by one step.

The operators Init and Next are specified to be the constructors of theMCA. This means that all possible MCA states are the result of systeminitialization and the advancement of the system state one step at atime by the Next operation. This specifies that the system cannot landin any “unspecified” states that might not satisfy the securityconstraints of the system. There is a similar constraint upon the SCAthat states that any SCA must be the result of a Fiber operation on anMCA. Since the MCA is constrained to be in valid states, as constructedby Init and Next, this constrains the SCAs to be in valid statesresulting from taking a Fiber of a valid MCA.

In sum, the system under consideration is the Multiple Cell Abstraction(MCA). The elements of the system to be separated are the cells asrepresented by the Single Cell Abstraction (SCA). The relationshipbetween the system and its cells is given in several forms by theabove-described fundamental equations. These fundamental equations inturn serve as the basis for the separation specification of the presentinvention.

The separation specification is further defined by two separationaxioms. FIG. 12 depicts a First Separation Axiom, which sets forth thecommunication policy between cells. Since the communication policyreferences the concept of a cell, it is logical that the statement ofthe communication policy should reference the definitions of the Nextand Fiber functions. Indeed, one of the purpose for separating thesystem into cells is to restrict communication within the system.Accordingly, FIG. 12 describes an equation stating that cell SCA_(x) caninfluence cell SCA_(y) only if cell SCA_(x) is permitted to communicatewith cell SCA_(y) by the communication policy enforced by the kernel.The communication policy is alternatively recited by the followingequations:

−Communications(x, y)

Fiber_(y)(MCA)=Fiber_(y)(Next_(x)(MCA))

Fiber_(y)(MCA)≠Fiber_(y)(Next_(x)(MCA))

Communicates(x,y)

In this case, the second equation (i.e., the contrapositive form of thefirst equation) states that if the fiber of cell y changes as the resultof advancing the state of cell x, it must be the case the x is permittedto communicate with y. In its positive form, the equation states that ifcell x cannot communicate with cell y, then whenever the state of cell xis advanced, there is no change in the state of y. A particularconsequence of this communication policy is that cell x can sendmessages to y only if cell x has permission to communicate with y.

The Second Separation Axiom is depicted in FIG. 13. It should be notedthat this diagram is not a commuting diagram. This diagram depicts thefollowing equations:

SCA _(1x)=Fiber_(x)(MCA ₁) SCA _(2x)=Fiber_(x)(MCA ₂)

SCA _(1y)=Fiber_(y)(MCA ₁) SCA _(2y)=Fiber_(y)(MCA ₂)

SCA′ _(1x)=Fiber_(x)(MCA′ ₁) SCA′ _(2x)=Fiber_(x)(MCA′ ₂)

SCA′ _(1y)=Fiber_(y)(MCA′ ₁) SCA′ _(2y)=Fiber_(y)(MCA′₂)

(Fiber_(x)(MCA ₁)=Fiber_(x)(MCA ₂))=>[((Fiber_(y)(MCA ₁)=Fiber_(y)(MCA₂))=>(Fiber_(y)(Next_(x)(MCA ₁)=Fiber_(y)(Next_(x)(MCA ₂))))]

Fiber_(y)(Next_(x)(MCA ₁))≠Fiber_(y)(Next_(x)(MCA ₂))=>(Fiber_(x)(MCA₁)≠(Fiber_(x)(MCA ₂))v(Fiber_(y)(MCA ₁)≠Fiber_(y)(MCA ₂))

In accordance with these equations, if an action by cell x (e.g.,advancing the state of the SCA for cell x) is going to change the stateof cell y, then the change in the state of y depends only on the statesof x and y. Without this axiom, an unknown cell could affect the stateof y. For instance, if x changes y, it could do so by copying everythingfrom a third cell z into the SCA of y. The purpose of this axiom is toprevent “undesirable” connections between cells such as z and y.

Accordingly, the first equation states that if x has the same fiber intwo different system states MCA₁ and MCA₂, and y has the same fiber inMCA₁ and MCA₂, then y has the same fiber after advancing the state x inboth MCA₁ and MCA₂. The contrapositive form of this equation (i.e., thesecond equation) may be more revealing. It says that if advancing xcauses a change in the state of y, then the change must have resultedfrom either a change in the state of x or a change in the state of y.

To implement a separation kernel, the designer must choose features thatsupport the intended applications and implement those features in a waythat conforms to the above-described separation property. In accordancewith the present invention, a computer-implemented system 90 thatsupports a high degree of separation between processing elements isshown in FIG. 14. The computer-implemented system 90 comprises aplurality of cells 92, where each cell includes a domain of execution 94and at least one processing element 96. A kernel 98 facilitatesexecution of the processing elements and administers the communicationbetween the processing elements in accordance with a separationspecification 99. The separation specification 99 governs communicationbetween the processing elements, such that one processing element caninfluence the operation of another processing element only as set forthby the separation specification.

A preferred implementation of the kernel and its separationspecification has selected several features that are required by theapplications of the kernel and can be made to fit the separationprinciple. First, memory allocation is a selected feature because theintended applications are required to process many kinds of data whichoften require added memory resources to efficiently process the data.Since the applications require time-shared access to hardware resources,the hardware resources are allocated as memory mapped segments to thecells in a way that preserves the separation property. Second, remoteprocedure call procedure is a selected feature because many intendedapplications require a communications mechanism beyond a simplesend-message. The remote procedure call is a communication mechanism inwhich information is provided to a server, the server processes theinformation and returns a result, and the processing continues in thesame context that existed before the service was invoked. Third,exception handling is a selected feature because the intendedapplications are required to be robust with respect to exceptions. Sinceexceptions can be handled locally with assurance that the direct causeof the exception is local, exception handling is also improved by theseparation principle. Each of these selected features (i.e., memoryallocation, remote procedure calls and exception handling) is furtherdescribed below.

A memory allocation mechanism in the separation kernel of the presentinvention is understood in relation to the operation of a strand asshown in FIG. 15. At strand launch time, a strand is allocated thememory it requires according to its predefined memory requirements. Thestrand memory requirements are constant for that strand, in that theyare the same each time the strand is launched. The strand receives twokinds of transient segments upon strand launch: message segments andnon-message segments. Message segments are segments, which have beensent by some other strand to the strand being launched. It is theexistence of this message that causes the strand launch. Non-messagesegments are the other transient segments, which are described by thepredefined memory requirements for the strand.

As the strand executes, it undergoes interactions with the kernel. Ifthe strand elects to send some of its transient segments as part of aninput message to another strand, then access to the transient segmentsis lost at this point. Thus, the strand can lose access to transientsegments as it executes, but it cannot gain access to any more transientsegments as it executes.

In order to achieve separation within the kernel, the allocation oftransient segments for a strand obeys the following properties: (1)before strand launch, the strand has access only to the permanentsegments of the cell; (2) transient memory requirements for a strand area function of the strand, and thus are known at compile time; (3) thekernel does not launch the strand until there is sufficient memory tosatisfy all of the memory requirements for the strand; (4) transientsegments that are non-message segments are initialized beforeallocation; (5) as the strand executes, it can lose memory segments(e.g., by sending a message), but it cannot allocate any more segments;and (6) strand termination causes all transient segments to be releasedby the kernel. From these properties, it may be concluded that afterstrand termination, the strand has access only to the permanent segmentsof the cell and each time a strand runs, the amount of memory availableis the same, as specified by the predefined memory requirements for thestrand. FIG. 18 illustrates a method for allocating memory by aseparation kernel in accordance with the above-described principles.

As a result, a strand sees exactly the same amount of allocated memoryeach time it runs. Thus, there is no covert channel stemming from theamount of allocated memory. This eliminates the typical memoryallocation covert channel that results from the ability of one processto cause resource exhaustion.

However, there may be still one covert channel if the memory addressesof the allocated transient segments are visible to the strand as itexecutes. In this case, it may be possible to manipulate the addressesof the available memory segments to communicate information to a strandto be launched. This channel can be eliminated if the underlyinghardware supports address translation. In this case, the strand wouldsee the allocated segments at the same logical address each time itruns. Thus, the strand would have the same amount of allocated transientmemory, at the same address, every time it runs.

Referring to FIG. 16, the separation kernel of the present inventionalso implements a remote procedure call mechanism. During the executionof the strand, the Strand₃ may makes a remote procedure call 92 toStrand₅ in the target cell (i.e., Cell_(B)). As part of the remoteprocedure call, some of the transient segments of the source strand aresent to the target strand. At this point, these transmitted segmentsbecome inaccessible to the source strand and accessible to the targetstrand. These transmitted segments constitute the parameters of theremote procedure call.

When the target strand is launched, the target strand only gets accessto the input transient segments and the permanent segments of the targetcell. Since there are no additional memory segments to allocate, it canbe concluded that there are sufficient resources to execute the remoteprocedure call. In other words, the remote procedure call cannot fail onaccount of insufficient resources. The kernel is designed to ensure thatinternal kernel resources will be sufficient to process the remoteprocedure calls, so that no resource exhaustion covert channel isprovided by the kernel itself Therefore, it is not possible for theremote procedure call to fail on account of insufficient resourceswithin the kernel.

In FIG. 16, the target strand terminates using the normal strandtermination mechanism. The target strand returns a value 94 to thecalling strand. In addition, the transmitted segments are madeinaccessible to the target strand and made once again made accessible tothe source strand. This means that before and after the remote procedurecalls the same set of segments are accessible to the source strand. Ifthe target strand is terminated for any other reason, the remoteprocedure call mechanism causes a return to the source strand, and thusguarantees a return from the remote procedure call.

During its execution, the target strand is prohibited from sending thetransmitted segments as part of a send message. Thus, the segmentsremain available to be returned to the source strand. Furthermore, thetarget strand can make a remote procedure call of its own. To do so, thetarget strand retransmits one or more of the transmitted segments toanother target strand. When this additional remote procedure call iscompleted, the re-transmitted segments are returned to the targetstrand.

It should also be noted that the remote procedure call mechanism doesnot allow recursive calls, i.e. calls to strands in a cell that isalready part of the remote procedure call stack. In addition, the remoteprocedure call mechanism also does not permit a call to a cell thatalready has an executing strand, thereby preserving the property thatonly one strand of a cell can run at any one time. This is an importantproperty to prevent re-entrant code. Re-entrant code can cause variousruntime errors. FIG. 19 illustrates a method for performing remoteprocedure calls in accordance with the above-described principles.

Lastly, the separation kernel of the present invention implements anexception handling mechanism. During the execution of a strand, thestrand may generate an exception. As will be apparent to one skilled inthe art, the exception may be caused by a variety of conditions,including a divide by zero or an invalid address condition (i.e., anaddress that is not within one of the segments accessible to thestrand). The strand can raise an exception intentionally by calling theThrow( ) interface as shown in FIG. 17.

The kernel in turn processes the Throw( )interface by transferringcontrol to the exception handler of the cell. The kernel also passes thecause of the exception in a register to the exception handler. Theexception handler runs in the same context as the strand that incurredthe exception. Therefore, the exception handler has access to the samepermanent and transient segments as the strand that incurred theexception.

The exception handler has the option of attempting to resume processingof the strand that incurred the exception or terminating the executionof the strand. In FIG. 17, it is assumed that the exception handlerresumes processing of the strand that incurred the exception. Thus, thestrand completes execution and then terminates.

Each strand has a maximum exception count. When the strand incurs anumber of exceptions equal to the maximum exception count, the strand isterminated by the kernel. Thus, there is no way to get stuck in a loopof exceptions, which in turn causes, more exceptions. On the contrary,the strand will be terminated when the maximum exception count isreached.

As a result of the above-described exception handling mechanisms,exceptions are confined to the cell that contains the strand thatincurred the exception. Accordingly, the exception handling mechanismenhances the separation property by providing exception handling that isseparate between cells.

The foregoing discloses and describes merely exemplary embodiments ofthe present invention. One skilled in the art will readily recognizefrom such discussion, and from accompanying drawings and claims, thatvarious changes, modifications, and variations can be made thereinwithout departing from the spirit and scope of the present invention.

Appendix

The data structures that define and describe the strands and cells inthe previously described framework are central to the cell abstractionconcept, the separation specification, and the implementation of aseparation kernel. Therefore, these data structures are defined topermit a better understanding of how the separation kernel may beimplemented in accordance with the present invention.

Cell Descriptions

All of the information in the cell descriptor is static informationabout the cell. There are four items in the cell descriptor:

-   -   PermanentSegmentList: The segments that are permanently        allocated to the cell. All the strands of the cell get access to        these segments when they run. These segments would typically        contain the code and cell state information for the application        represented by the cell. Permanent segments can be restricted to        a single cell or can be shared between more than one cell. The        permanent segment list described the access mode to the segment        (some combination of read, write, and execute) desired by the        cell.    -   Handler: The address of the exception handler for the cell.    -   SendMap: The set of cells to which this cell can send messages.        This regulates the operation of the kernel Send( )and Wait(        )interfaces.    -   ShareMap: The set of cells with which this cell can share        permanent segments.

Cell State

The cell state is dynamic information about the cell. It is maintainedas a map from CellID to CellState, where CellState is one of Idle,Running, or Waiting. This mapping is called the CellStateMap.

Strand Descriptor

All of the information in the strand descriptor is static informationabout the strand. There are seven items in the strand descriptor:

-   -   CellID: The identifier of the cell that contains the strand.        This can be used to look up the cell descriptor of the cell        containing the strand.    -   ProcessorMode: Either foreground or background. If the mode is        foreground, the cell is run with interrupts enabled. If the mode        is background, the cell is run with interrupts disabled. A        background cell can be used to implement a device driver strand,        which requires access to hardware resources without fear of        interrupt from the hardware.    -   EntryPoint: The address of the StrandEntryPoint function.    -   StackPointer: Where to begin the stack when the StrandEntryPoint        is run. The stack pointer must point at an address within a        permanent segment of the cell of the strand, or to an assigned        segment required by the strand in the SDAssignedSegmentList. The        kernel table builder, not the kernel itself, enforces this        restriction.    -   Priority: The priority of the strand.    -   ScratchSizeMap: The scratch memory requirements of the strand.        There are four sizes of scratch segments: Tiny, Small, Medium        and Large. The scratch size map defines how many of each of        these scratch segments sizes are required by the strand.    -   SDAssignedSegmentList: The assigned segments required by the        strand. Assigned segments are used to share scarce resources        between strands.        The strand descriptors are kept in the StrandDescriptorTable,        which is a total mapping from StrandID to StrandDescriptor.

Initial Strand

There is a configuration parameter called InitialStrand used by thekernel. This is static strand information. When the kernel has completedinitialization, it launches the strand indicated by the InitialStrandconfiguration parameter.

Resource Availability for a Strand

A concept that comes up repeatedly in the description of the kernel isresource availability, so it is discussed separately here to aidunderstanding of the description of the kernel.

Execution of a strand may require allocation of resources. The resourcesthat may be allocated are scratch and assigned segments. Resourceavailability for a strand means:

-   -   There are enough available scratch segments of the sizes        specified in the ScratchSizeMap of the StrandDescriptor.    -   The assigned segments required by the strand are all available.        This can mean one of the following:        -   The assigned segments are completely free.        -   The assigned segments are part of the message to launch the            strand.        -   The assigned segments have been kept by the strand on the            prior execution of the strand.

Runnability of a Strand

A related concept to resource availability for a strand is therunnability of a strand. A strand is runnable when:

-   -   The resources required by the strand are available.    -   The strand is not marked blocked.

Strand Startup

When a strand begins, it has several standard arguments, which arepassed to it by the kernel. The parameters are passed utilizing theregisters/stack. The strand must have sufficient stack space for thestacked parameters along with any space necessary for local data. Thevariables that are initialized with their values and available for astrand to use when it starts are as follows:

-   -   SourceStrandID is the ID of the strand, which sent the message.    -   Command is a 32-bit message from the sending cell.    -   ScratchSegmentList is a structure consisting of the number of        scratch segments along with each segment's address and size.    -   Message is a structure consisting of the number of message        segments along with each segment's address and size.    -   Depth represents the level of nested Remote Procedure Calls        (RPC) that this strand is being started within. A length of zero        means that the strand is being started by a Message_Send call. A        length which is greater than zero, represents the number of        nested RPCs.

Exception Handling

Exception processing allows a strand to transfer control to theexception handler specified in the cell descriptor for the cell. Thisfeature is similar to a jump and should be used to handle cases whereabnormal conditions arise.

The exception code is the only parameter passed to the exception handlerby the currently running strand. The exception code should contain theerror code that resulted in the exception. Preferably, the systemreserves the first 32 exception codes (0→31) for current and futuregrowth. Each cell is free to use the other exception codes as needed.

1. A method for performing a remote procedure call from a source taskresiding in a source cell to a target task residing in a target cell,the source task having a memory space accessible during execution of thesource task, comprising the steps of: sending an input message from thesource task to the target task, where the input message is a portion ofthe memory space associated with the source task and the portion of thememory space is inaccessible to the source task during the execution ofthe target task; initiating execution of the target task in the targetcell in response to receiving the input message from the source task;providing access to the portion of the memory space during execution ofthe target task; releasing the portion of the memory space such that theportion of the memory space is accessible to the source task; andproviding a return message from the target task to the source task uponcompleting execution of the target task.
 2. The method of claim 1,further comprising the step of prohibiting the target strand fromsending a second input message, where the second input messagecorresponds to the portion of the memory space received from the sourcetask.
 3. The method of claim 1, further comprising the steps of:limiting access of the target task to a plurality of input transientsegments and a plurality of permanent segments of the target cell; andproviding a sufficient resource to execute the remote procedure callbased at least in part on the limiting access of the target task to aplurality of input transient segments and a plurality of permanentsegments of the target cell.
 4. The method of claim 3, furthercomprising the step of prohibiting a resource exhaustion covert channelbased at least in part on the providing the sufficient resource toexecute the remote procedure call.
 5. The method of claim 1, furthercomprising the step of prohibiting a call to a task in a cell that isalready a part of a stack of the remote procedure call.
 6. The method ofclaim 1, further comprising the step of prohibiting a call to a targetcell having an executing task.